-
Notifications
You must be signed in to change notification settings - Fork 14k
Fix/Make proc_macro span_close() and span_open() more accurate after set_span() calls #149052
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
rustbot has assigned @petrochenkov. Use |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
I think it would be better to test the opening/closing span recovery strategy on the compiler first, and then do the same for proc macros.
|
I can look at adding something to the compiler side of things first. I suppose we could inspect parts of the stream itself if that is desired. However, at least on the proc_macro side I did not do that. That's because someone could assign a span not directly associated to the underlying stream that the group contains. Therefore, inspecting the stream may not provide any useful information. Thusly, I chose what I did since it would more accurate in most cases than just using the whole span. From a quick look the As for the four options:
As for the diagnostic output is there anything you're particularly looking for or wanting to avoid when you mention experimentally testing? |
I was not suggesting to inspect token stream, "source map" is some source text to which all spans map, not tokens. |
Just want to look at the results with different options for a start. |
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
When `Group::set_span()` is called the spans for `Group::span_open()` and `Group::span_close() ` methods just become the whole span instead of the spans the delimiters. This ensure this have at least a more useable value after a call to `Group::set_span()`.
So I have here the Honestly, in the compiler I would say that it might better to have not just some catch all This still does nothing about my main concern though about fixing the |
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Could you update the tests (to make CI green) and submit the compiler changes in a separate PR? |
|
Reminder, once the PR becomes ready for a review, use |
When
Group::set_span()is called the span's forGroup::span_open()andGroup::span_close()methods just become the whole span instead where it should be the span of the delimiters. This PR ensures they have at least a more usable value after a call toGroup::set_span().Here is a kinda of motivating example of this issue I observed. If you compare the current behavior the outputs the diagnostics will not be on the opening and closing delimiters after calling set span. If you look at the outputs after using this PR they will match. Further, afterward
Span::eq()then evaluates to true which nice to see.This is all I did to invoke the proc_macro example above.